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DRAFT 



This memo represents a preliminary attempt at specifying what the proposed debugger 
interpreter will look like. A full interpreter at this point seems unreasonable and probably 
of marginal value. However, a minimal subset of the language would be a valuable 
extension to the current debugger command language. 

We have specified the following subset of the Mesa TYPE calculus as being acceptable to 
this interpreter: 

--dot notation: a.bx 

--assignment: ^ 

--dereference: f 

—indexing: [J 

—addressing: "©expression" 

-LOOPHOLE 
With the help of some of the compiler's modules we will be able to enforce strong type- 
checking in the interpreter. 

The proposed interpreter should help to alleviate many of the problems regarding displaying 
and assigning values to complicated data structures that now force the user to go down to 
octal level debugging. 



In terms of the 
the following 

Expression 

AddingOp 

AssignmentExpr 

Conjunction 

Disjunction 

Factor 

IndexedAccess 

IndirectAccess 

Leftside 



Literal 



formal Mesa syntax the grammar for the proposed interpreter should include 

expressions: 
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AssignmentExpr | Disjunction 

+ I - 

Leftside <- RightSide 

Negation | Conjunction AND Negation 

Conjunction | Disjunction OR Conjunction 

- Primary 1 Primary # O^ Pages 

( Expression ) [ Expression ] | Variable [ Expression ] 

{ Expression ) t j Variable t 

Identifier | -- Call in Statement 

IndexedAccess I QualifiedAccess | IndirectAccess I 

LOOPHOLE [ Expression ] | 

LOOPHOLE [ Expression , TypeSpeclfication ] 

numericLiteral j -- all defined outside the grammar 
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stringLiteral I 
characterLiteral 

MuItiplyingOp ::= * I / I MOD 

Negation ::= Relation j Not Relation 

Not ::= - I NOT 

Primary ::= Variable | Literal I ( Expression ) | @ LeftSide 

Product ::= Factor | Product MuItiplyingOp Factor 

QualifiedAccess ::= ( Expression ) . identifier | Variable . identifier 

Relation ::= Sum | Sum RelationTail 

RelationalOp ::= # | = | < j <= j > j > = 

RelationTail ::= RelationalOp Sum I Not RelationalOp Sum I 
IN SubRange I Not IN Subrange 

RightSide ::= Expression 

Subrange ::= SubrangeTC | Typeldentifier -- SubrangeTC, Typeldentifier In TypeSpecification 

Sum ::= Product | Sum AddingOp Product 

Variable ::= LeftSide 



There are some questions in my mind about including the following expressions (we should 
discuss these further): 



Expression 

IfExpr 
BuiltinCall 



IfExpr 

IF Expression THEN Expression ELSE Expression 

MIN [ ExpressionList ] I MAX [ ExpressionList ] | ABS [ Expression ] j 

LENGTH [ Expression ] | BASE [ Expression ] j 

TypeOp I TypeSpecification ] | 

DESCRIPTOR [ Expression ] j 

DESCRIPTOR [ Expression , Expression ] | 

DESCRIPTOR [ Expression , Expression , TypeSpecification ] 

empty I Expression 

KeywordComponentList | PositionalComponentList 

OptionalTypeld [ ComponentList ] 

Expression | ExpressionList , Expression 

BuiltinCall | Call 

:= identifier : Component 



Component 

ComponentList 

Constructor 

ExpressionList 

FunctlonCall 

KeywordComponent 

KeywordComponentList ::= 

KeywordComponent | 
KeywordComponentList , KeywordComponent 

Leftside ::= Call | MEMORY [ Expression ] | REGISTER [ Expression ] 

PositionalComponentList ::= 

Component | 
PositionalComponentList , Component 

Primary ::= FunctlonCall I Constructor 

TypeOp ::= SIZE I FIRST | LAST 



The following expressions seem to be of marginal value to consider including: 



Expression 

NewExpr 

SelectExpr 

SelectExprSimple 

SelectExprVariant 
ChoiceList ::= 



-- Leftltem in Statement 



NewExpr | SelectExpr 

NEW Variable OptCatchPhrase 

SelectExprSimple j SelectExprVariant 

::= SELECT Leftltem FROM 
ExprChoiceList 
ENDCASE => Expression 

::= WITH Openltem SELECT Tagltem FROM— Openltem, Tagltem in 

AdjectiveLlst => Expression , | -- AdjectiveList in Statement 

ChoiceList AdjectiveList => Expression , 
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ExprChoiceList ::= TestList => Expression , | -- TestList in Statement 

ExprClioiceList TestList => Expression , 

Remaining Questions: 

--whether the interpreter should use the same scanning mechanism as the compiler; the 

current thought seems to be to keep it a separate mechanism and have it build its own trees 

with information relevant to interpreting the value of expressions 

--what sort of user interface to have for the interpreter; whether the present set of Interpet 

commands should be replaced simply by one INTERPRET command or accept interpreted 

values as input for all commands 

--what kind of procedure calls to allow, if any - for instance, how about interpret call of 

nested procedures and returning large parameter records 

--whether we should allow user-defined temporary variables 

--the above specified grammar is an expression evaluator - what about evaluating 

statements (and multiple statements) 

--what context to evaluate in (current module, current configuration, defs.foo) 

— expandint to conditional breakpoints 
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